default XEN_PRIVILEGED_GUEST
help
Assume access is available to physical hardware devices
- (e.g., hard drives, network cards). This allows you to configure
- such devices and also includes some low-level support that is
- otherwise not compiled into the kernel.
+ (e.g., hard drives, network cards). This allows you to configure
+ such devices and also includes some low-level support that is
+ otherwise not compiled into the kernel.
config XEN_BLKDEV_BACKEND
- bool "Block-device backend driver"
- depends on XEN_PHYSDEV_ACCESS
- default y
- help
- The block-device backend driver allows the kernel to export its
- block devices to other guests via a high-performance shared-memory
- interface.
+ bool "Block-device backend driver"
+ depends on XEN_PHYSDEV_ACCESS
+ default y
+ help
+ The block-device backend driver allows the kernel to export its
+ block devices to other guests via a high-performance shared-memory
+ interface.
+config XEN_BLKDEV_TAP_BE
+ bool "Block Tap support for backend driver (DANGEROUS)"
+ depends on XEN_BLDEV_BACKEND
+ default n
+ help
+ If you intend to use the block tap driver, the backend domain will
+ not know the domain id of the real frontend, and so will not be able
+ to map its data pages. This modifies the backend to attempt to map
+ from both the tap domain and the real frontend. This presents a
+ security risk, and so should ONLY be used for development
+ with the blktap. This option will be removed as the block drivers are
+ modified to use grant tables.
+
config XEN_NETDEV_BACKEND
- bool "Network-device backend driver"
- depends on XEN_PHYSDEV_ACCESS
- default y
- help
- The network-device backend driver allows the kernel to export its
- network devices to other guests via a high-performance shared-memory
- interface.
+ bool "Network-device backend driver"
+ depends on XEN_PHYSDEV_ACCESS
+ default y
+ help
+ The network-device backend driver allows the kernel to export its
+ network devices to other guests via a high-performance shared-memory
+ interface.
config XEN_BLKDEV_FRONTEND
- bool "Block-device frontend driver"
- default y
- help
- The block-device frontend driver allows the kernel to access block
- devices mounted within another guest OS. Unless you are building a
- dedicated device-driver domain, or your master control domain
- (domain 0), then you almost certainly want to say Y here.
+ bool "Block-device frontend driver"
+ default y
+ help
+ The block-device frontend driver allows the kernel to access block
+ devices mounted within another guest OS. Unless you are building a
+ dedicated device-driver domain, or your master control domain
+ (domain 0), then you almost certainly want to say Y here.
config XEN_NETDEV_FRONTEND
- bool "Network-device frontend driver"
- default y
- help
- The network-device frontend driver allows the kernel to access
- network interfaces within another guest OS. Unless you are building a
- dedicated device-driver domain, or your master control domain
- (domain 0), then you almost certainly want to say Y here.
+ bool "Network-device frontend driver"
+ default y
+ help
+ The network-device frontend driver allows the kernel to access
+ network interfaces within another guest OS. Unless you are building a
+ dedicated device-driver domain, or your master control domain
+ (domain 0), then you almost certainly want to say Y here.
config XEN_NETDEV_FRONTEND_PIPELINED_TRANSMITTER
- bool "Pipelined transmitter (DANGEROUS)"
+ bool "Pipelined transmitter (DANGEROUS)"
depends on XEN_NETDEV_FRONTEND
- default n
- help
- The driver will assume that the backend is pipelining packets for
- transmission: whenever packets are pending in the remote backend,
- the driver will not send asynchronous notifications when it queues
- additional packets for transmission.
- If the backend is a dumb domain, such as a transparent Ethernet
- bridge with no local IP interface, it is safe to say Y here to get
- slightly lower network overhead.
- If the backend has a local IP interface; or may be doing smart things
- like reassembling packets to perform firewall filtering; or if you
- are unsure; or if you experience network hangs when this option is
- enabled; then you must say N here.
+ default n
+ help
+ The driver will assume that the backend is pipelining packets for
+ transmission: whenever packets are pending in the remote backend,
+ the driver will not send asynchronous notifications when it queues
+ additional packets for transmission.
+ If the backend is a dumb domain, such as a transparent Ethernet
+ bridge with no local IP interface, it is safe to say Y here to get
+ slightly lower network overhead.
+ If the backend has a local IP interface; or may be doing smart things
+ like reassembling packets to perform firewall filtering; or if you
+ are unsure; or if you experience network hangs when this option is
+ enabled; then you must say N here.
- bool "Block device tap driver"
- default n
- help
- This driver allows a VM to interact on block device channels
- to other VMs. Block messages may be passed through or redirected
- to a character device, allowing device prototyping in application
- space. Odds are that you want to say N here.
-
+config XEN_BLKDEV_TAP
++ bool "Block device tap driver"
++ default n
++ help
++ This driver allows a VM to interact on block device channels
++ to other VMs. Block messages may be passed through or redirected
++ to a character device, allowing device prototyping in application
++ space. Odds are that you want to say N here.
+
config XEN_WRITABLE_PAGETABLES
bool
default y
projects / xen.git / commitdiff